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(57) An object pointer data structure for efficiently 
combining an object identifier and an object address for 
use in object-oriented programming systems. An object 
address is a value that allows a client application or proc- 
ess to conduct high-performance operations on an ob- 
ject in the client's local virtual address space. An object 
identifier is a value that can be used to uniquely identify 
an object for the lifetime of that object across some de- 
fined domain, such as an entire universe of computer 
systems. The data structure of this invention defines an 
object pointer that is larger than the object address but 
smaller than the combination of the object identifier and 
object address. The truncated object pointer structure 
preserves all information from both object address and 
object identifier by forcing a portion of the local object 
address in each address space to be equal to a portion 
of the invariant object identifier. A local pointer mapping 
table may be used for efficiency in assigning local ad- 
dresses to restored objects in each process. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates generally to addressing ob- 
jects in an object-oriented programming environment 
and more particularly to a system and method for com- 
bining a global object identifier with a local object ad- 
dress in a single object pointer. 

2. Discussion of the Related Art 

Large computer systems permitting many users to 
simultaneously use single computer resources are here- 
in denominated multitasking computer systems. Such 
multitasking systems can be interconnected through net- 
works to permit concurrent processing over a distributed 
plurality of computer resources. The concurrent activities 
of a large number of simultaneous users are managed 
by an operating system, which must provide the neces- 
sary data structures for tracking and controlling many 
concurrent processes. Requisite data structures include 
those needed to manage the distributed memory and the 
multiple central processing unit (CPU) resources that are 
used by user processes throughout the network. 

If every user process were completely independent, 
having its own dedicated resources : and there were no 
concerns about which resources each process must use ; 
operated systems could be relatively simple. However, 
networked or distributed computer resources are usually 
shared by many user processes, each requiring access 
to commonly-owned resources. In fact, each user proc- 
ess may generate a number of simultaneous execution 
threads that must also share resources among them- 
selves and communicate with the threads and processes 
of other users. 

Modern operating systems employ object architec- 
tures to govern data access and transfers among con- 
current processes. As used herein, objects include data 
structures holding information that must be protected 
from unauthorized access by other user processes. Ob- 
jects are created by the operating system responsive to 
user requests and are structured to permit access by the 
requesting user through system routines that protect the 
integrity of each object. 

The concepts of object identifier and object address 
(or reference) are well-known in the typical object-orient- 
ed programming art. As used herein, an object identifier 
denominates a value that can be used to uniquely iden- 
tify an object for the lifetime of that object across some 
defined domain, such as a single system, a network of 
systems or the set of all systems in some predefined uni- 
verse. As used herein, an object address (or reference) 
denominates a value that allows a user application to 
conduct high-performance operations on an object in a 
local virtual address space assigned to the associated 



user application process. An object address need not be 
unique in any domain broader than the local virtual ad- 
dress space in which it is used. As known in the art the 
concepts of object identifier and object address are sep- 
5 arate and distinct. 

An object identifier is needed to identify an object 
having a lifetime that exceeds its local address lifetime. 
Object identifiers are used, for instance, to manage a 
network of objects, herein denominating a structure em- 
bracing a multiplicity of objects linked together by stored 
object identifiers each linked to an object within the mul- 
tiplicity. When an object must be moved from one system 
to another or from one process to another for instance, 
to permit controlled access by many different users, the 
only consistent means available for tracking such objects 
is the object identifier, which remains invariant during the 
interprocess transition from one virtual address space to 
another 

Because object address and object identifier are 
conceptually distinct and have independent values, the 
systems programmer must provide for both. For in- 
stance, storage must be allocated for both, storing and 
updating operations must be allocated for both and so 
forth. This doubled complexity reduces programming 
productivity and increases the probability of program- 
ming error. There is., accordingly a clearly-felt need in 
the art to provide both functions in a single data structure. 
Although this could be accommodated merely by con- 
catenating the two values into a single double-sized data 
structure, such a solution offers no reduction in program- 
ming complexity because no storage allocation or updat- 
ing operations are thereby avoided. 

Practitioners in the art have proposed a number of 
solutions to the object-oriented programming complexity 
problem. For instance, one solution uses a server proc- 
ess that temporarily impersonates the characteristics of 
a client process when the client process performs a re- 
mote procedure call on the server process in a multitask- 
ing system. This impersonation is accomplished by cre- 
ating a new object identifier list that is either the same as 
the client process list or represents the union of the serv- 
er and client lists. Such an access control list is provided 
in each object to define those identifiers required to ac- 
cess the object. Thus, when the identifier list is modified 
to map all necessary identifiers to local addresses, ac- 
cess checking software in the operating system may 
then enable the impersonating process to access the 
specified object. This solution arguably increases pro- 
gramming complexity to accomplish the necessary ma- 
nipulation of mapping tables that relate object identifiers 
to local addresses. 

Similarly another solution uses a system for creat- 
ing "conditional" objects having different object pointers 
for accessing selected system resources. This ob- 
ject-based operating system supports multiple levels of 
visibility, thereby permitting objects to be manipulated 
only by processes within the object's "range" of visibility. 
An object or an object network can be moved up to a 
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higher visibility level for more object sharing and down 
to a lower visibility level for more restricted or privileged 
access. The visibility restriction is achieved by giving 
each process a pointer (object identifier) to its own proc- 
ess-level container directory and providing for a "public 5 
display" container directory permitting interprocess ob- 
ject access. Thus, such a scheme requires a multiplicity 
of different directories and object identifier mapping ta- 
bles within each process for linking each global object 
identifier to various local virtual addresses, increasing 10 
rather than reducing programming complexity. 

Another approach achieves a virtual look-aside fa- 
cility for maintaining named data objects in class-related 
data spaces in virtual storage by providing for an ordered 
list of "major names" within each user process that is se- is 
quentially searched for a specified "minor name" to ob- 
tain a virtual storage copy of a data object. This requires 
a control structure designed to capture information about 
the location of data within a tree structure that is implicitly 
created by a naming technique that is commonly used 20 
during routine caching operations. This information 
by-product, selectively used to improve performance in 
subsequent transactions, does nothing to reduce the 
programming complexity associated with object naming 
conventions. 25 

Also known in the art is an object identifier generator 
for producing unique identifiers in a distributed computer 
system by concatenating the identifier of the creating 
node firstly with a creation time from an associated clock 
adjusted to ensure uniqueness., secondly with a random 30 
name-sequence, and finally with a system version 
number. This generator ensures the creation of an object 
identifier that is unique across an indefinite universe of 
computer systems but does not affect the programming 
complexity problem. 35 

Other related approaches include a system environ- 
ment that employs workspace name tables for linking 
packaged workspaces (user processes). An active work- 
space accesses a loaded copy of the packaged work- 
spaces using the external names of named objects in a -to 
packaged workspace rather than the internal names of 
its own named objects. This system is controlled through 
a packaged workspace name table stored in the active 
workspace, which can be merged with other name tables 
from other packaged workspaces and also shared 45 
among a plurality of active workspaces. As with other 
known object identifier to local address mapping 
schemes, this system merely maps object identifiers to 
local addresses and does nothing to reduce program- 
ming complexity. 50 

It can be appreciated from the above survey that 
practitioners in the art, until now, appear to rely on map- 
ping tables with controlled access and duplication privi- 
leges to establish and control the relationship between 
global object identifiers and local virtual addresses, 55 
which does nothing to improve programming efficiency. 
The related unresolved deficiencies are clearly felt in the 
art and are solved by this invention in the manner de- 



scribed below. 

SUMMARY OF THE INVENTION 

The system of this invention introduces a new data 
structure and a process that preserves part of the object 
identifier in each new local address selected for an object 
that is transferred into a new virtual address space. By 
preserving this part of the object identifier, a single trun- 
cated pointer is then sufficient to carry all object identifier 
and object address information. A local mapping table 
may be used to manage local address assignments but 
is not essential to the system of this invention. 

It is an object of the system of this invention to pro- 
vide an efficient mechanism for combining an object 
identifier and an object address into a single object point- 
er that provides the features of both. It is an advantage 
of the system of this invention that a single object pointer 
is sufficient for both global object identifier and local ob- 
ject address with less complexity and in less space than 
is required separately for both. 

It is another object of the system of this invention to 
provide such an object pointer that can be controlled and 
manipulated by the operating system as a single data 
structure to reduce programming complexity. It is a fea- 
ture of the data structure of this invention that both object 
identifier and object address information is contained in 
one object pointer that appears to the operating system 
to be a single data structure. 

The foregoing, together with other objects, features 
and advantages of this invention, can be better appreci- 
ated with reference to the following specification, claims 
and the accompanying drawing. 

BRIEF DESCRIPTION OF THE DRAWING 

For a more complete understanding of this inven- 
tion, reference is now made to the following detailed de- 
scription of the embodiments, as illustrated in the accom- 
panying drawing, wherein: 

Fig. 1 is a functional block diagram showing a mul- 
titasking computer system from the prior art: 

Fig. 2 is a functional block diagram illustrating the 
virtual memory spaces of several exemplary concur- 
rent processes: 

Figs. 3A-3B illustrate the object identifier and object 
address data structure parsing of this invention: 

Figs. 4A-4B show an exemplary embodiment of the 
hybrid pointer data structure of this invention: 

Fig. 5 illustrates an exemplary object mapping table 
embodiment of this invention: 

Fig. 6 is a functional block diagram illustrating the 
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object pointer mapping control procedure of this 
invention: 

Fig. 7 is a functional block diagram illustrating the 
lazy object pointer mapping procedure of this inven- 
tion for networked objects: and 

Fig. 8 is a functional block diagram of an exemplary 
embodiment of the object pointer system of this 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The system of this invention is an object-oriented 
programming structure suitable for application to multi- 
tasking systems. In general, object-oriented program- 
ming structures include data structures and procedures 
that control user-definable objects. As used herein, "ob- 
jects" are data structures holding information that is used 
by the operating system or by user applications. For in- 
stance, a "process object" is a particular object type 
known in the art for storing information required by the 
operating system to track the status of a particular user 
process. 

A "process" is the entity to which a virtual memory 
address space is assigned by the operating system and 
also is the entity to which process-level objects are as- 
signed. As is known in the art, a particular user may em- 
ploy multiple processes simultaneously. Whenever a 
particular user demands system resources, a "top lever 
process is created to manage all related activities. Any 
process, including any user process or the top level proc- 
ess, may cause the creation of additional processes, de- 
nominated subprocesses or "child" processes. Thus, 
any "parent" process may create one or more "child" 
processes. 

Fig. 1 illustrates a computer system 1 0 that is typical 
of multitasking computer networks known in the art. Sys- 
tem 10 includes a high-speed central processing unit 
(CPU) 12 that concurrently runs the several processes 
14, 16, 18 and 20. CPU 12 may be either a single proc- 
essor or may include multiple distributed processors. 
Each process 14-20 is associated with its own virtual 
memory space : which is mapped in part into high-speed 
primary memory 22 and in part into lower-speed second- 
ary memory 24 by a virtual memory manager 26. Each 
process 1 4-20 is allocated a portion of the available com- 
puter resources, including selected peripheral devices 
such as terminals 28 and 30 and other input-output (I/O) 
devices 32 and 34. Process allocations also include 
specified sets of data and data structures in the distrib- 
uted memory 22 and 24. 

Operation and resource allocation in computer sys- 
tem 10 is supervised by the operating system 36 which 
resides in primary memory 22 for most purposes. Multi- 
tasking computer system 10 may also include one or 
more remotely-located computer systems, exemplified 



by remote computer 38, which may include other termi- 
nals. I/O devices, primary and secondary memory devic- 
es and the like (not shown). Data communications 
among CPU 12. peripheral devices 28-34 and remote 
5 computer 38 are controlled by a bus interface 40 in one 
of several fashions known in the art. 

Fig. 2 shows a functional block diagram illustrating 
the allocation of virtual memory space for several con- 
current user processes 1 4-18. The virtual memory space 
io associated with each process includes a virtual address 
space, exemplified by virtual address space 42 for proc- 
ess 14, that can be accessed by "user mode" programs 
as well as "kernel mode" programs having system-wide 
privilege, including "executive" mode 44, "kernel" mode 
? s 46 and "hardware" mode 48 privilege levels known in the 
art. The virtual memory space 44-48 allocated to kernel 
mode is common to all user processes running in the 
multitasking computer system 10. Thus, a predefined 
portion (44, 46 and 48) of the virtual memory space as- 
sociated with each user process is occupied by operating 
system 36 and its data structures. The user mode portion 
42 occupies the remainder of the associated virtual 
memory space assigned to the user process 14. 

When a user mode program, exemplified by a user 
call 50 in user process 1 4, creates an object or performs 
an operation on an object., user process 1 4 calls a kernel 
mode routine 52 in the executive portion 44 of the asso- 
ciated virtual memory space to perform the necessary 
object-creation operations. After completion of kernel 
routine 52, control is returned to user program 50 in proc- 
ess 14. Thus, kernel mode programs are responsible for 
objection creation and object transfers between inde- 
pendent user processes, such as an object transfer be- 
tween user process 14 and 16, for instance. Thus, as is 
well-known in the object-oriented programming art. op- 
erating system 36 (through kernel mode programs) is 
privileged to move objects among user processes 1 4-20 
even though each such user process is associated with 
a completely independent virtual address space, exem- 
plified by virtual address space 42. 

Fig. 3A illustrates an object identifier 54 that is cre- 
ated by concatenating an address space identifier 56. 
representing the virtual address space in which the iden- 
tified object was first created, to a local object address 
58, representing the first virtual address for the identified 
object. This particular known method for creating object 
identifier 54 is arbitrary but useful because it ensures cre- 
ation of a unique object identifier for each new object in 
system 10. 

Fig. 3B illustrates a local object address 60 that is 
created by concatenating a segment identifier 62 in a vir- 
tual address space with an offset 64, representing the 
precise storage location of the object within segment 62 
of the associated virtual address space. 

Fig. 4A illustrates the data structure of the object 
pointer 66 of this invention. By defining pointer 66 to be 
larger than object address 60, enough information can 
be stored in pointer 66 to identify both object address 60 
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and object identifier 54. Instead of using the simple meth- 
od of appending object identifier 54 to object address 60, 
which forces object pointer 66 to become unnecessarily 
large, the unexpectedly advantageous solution of this in- 
vention involves preserving some of object identifier 54 
in object address 60. This solution opposes the usual 
practice of preserving address 60 in identifier 54 ; and is 
illustrated in more detail in Fig. 4B ; which summarizes 
the various parsings of this invention for structures 54, 
60 and 66. 

Although Fig. 3B shows object address 60 to be a 
virtual address logically divided into segment ID 62 and 
offset 64, and Fig. 3A shows object identifier 54 to be 
logically divided into address space identifier 56 and lo- 
cal object identifier 58, the method of this invention im- 
poses a more general and useful parsing on these par- 
ticular structures. This generality can be appreciated 
from Fig. 3A wherein object identifier 54 is divided into a 
first part (I) 68 and a second part (J) 70. Similarly, in Fig. 
3B, object address 60 is divided into a first part (A) 72 
and a second part (B) 74. Parts (I) 68 and (J) 70 do not 
necessarily align with identifiers 56 and 58. Similarly, 
parts (A) 72 and (B) 74 do not necessarily align with seg- 
ment identifier 62 and offset 64, 

Pointer 66 includes three or four parts. These are a 
first part (P) 75 corresponding to first part (I) 68 from ob- 
ject identifier 54; a second part (Q) 76 corresponding to 
first part (A) 72 from object address 60: a third part (R) 
77 corresponding both to second part (J) 70 from object 
identifier 54 and second part (B) 74 from object address 
60: and an optional fourth part (S) 78. which is useful for 
internal object pointer flagging purposes as discussed 
below. 

Considering, as a specific example, the IBM AS/400 
addressing architecture known in the art, segment ID 62 
is 40 bits long, offset 64 is 24 bits long, and address 
space identifier 56 can be a 32-bit value that is sufficient 
to uniquely identify the virtual address generator that pro- 
duced the original local object address 58. which is 
40+24=64 bits in length. Thus, object identifier 54 is 
64+32^96 bits or 12 bytes (12B) in length. Object ad- 
dress 60 is 64 bits = 8B in length. These exemplary val- 
ues imply that l+J=12B and A+B=8B, which are gener- 
ous considering that address space identifier 56 could 
be associated with an entire system (not just a process). 
A 32-bit address space identifier 56 permits the combi- 
nation of up to four billion individual systems divided by 
the typical number of times each system is reloaded from 
scratch during its lifetime. Accordingly, a 1 2B object iden- 
tifier 54 should be unique across all existing systems 
over all time. A more general object identifier that is 
unique across all heterogeneous systems, such as sys- 
tem 10 discussed above in connection with Figs. 1 and 
2, merely requires appending an identifier field that 
uniquely distinguishes them from other system types. 

The one byte type field (S) 78 in Figs. 4A-4B is used 
in the AS/400 system to distinguish various pointer types 
and to flag whether the pointer is "resolved" or not. In an 



illustrative embodiment of object pointer 66. the object 
identifier prefix 79 is set to 7B in length, which sets the 
size of first part (I) 68. With an 8B length for object ad- 
dress 60, the entire length of object pointer 66 (SPQR) 
s is 1 B+7B+8B=1 6B. Because object identifier prefix 79 is 
7B long, the object identifier suffix 80 is 12B-7B=5B in 
length, leaving 8B-5B=3B for the segment identifier 
(SID) block 82, which sets the size of first part (A) 72 in 
object address 60. 
10 The 5B overlap of object ID suffix 80 with virtual ad- 
dress 60 is simple to implement when an object is first 
created because local object identifier 58 is then identical 
to the object's original virtual address 60 in the base vir- 
tual address space. An important advantage of the sys- 
'5 tern of this invention is the ease of managing the 5-byte 
overlap when an object is moved from one process to 
another. This is accomplished by choosing an available 
8B address (A^) in the target virtual address space 
such that the five object identifier suffix bytes are the 

20 same as they were in the previous process. In other 
words, referring to Fig. 4B, object address (AB) 72-74 is 
chosen such that field (B) 74 is equal to field (J) 70, both 
of which are preserved in pointer field (R) 77. With a 
40-bit long object ID suffix 80, 24 bits of freedom remain 

25 m field (A) 72 for assigning an address based on SID 
block 82. The 24 bits of freedom in assigning new virtual 
addresses can be traded off against the number of avail- 
able address spaces (the size of address space identifier 
56). The specific field lengths mentioned above for this 

30 embodiment are exemplary only and do not serve to limit 
the application of the system of this invention. For in- 
stance, object identifier suffix 80 may be smaller than 
SID block 82 for improved address generation flexibility. 
Fig. 5 shows two processes 14 and 16 each includ- 
es ing a mapping table exemplified by mapping table 84 in 
process 14. Mapping table 84 may be used to more ef- 
ficiently allocate local object addresses (AB) in a partic- 
ular virtual address space, as discussed below. Although 
many different procedures can be used to efficiently 

io manage the selection of values for SID block 82 (field 
(Q) 76 of pointer 66), one useful approach is now de- 
scribed in connection with Fig. 6. 

In Fig. 6, an object is first created at step 86 in a base 
process. In step 88, an address generator assigns an 

*s address (A 0 B 0 ) to the locally-created object (IJ). For 
management purposes, the address generator chooses 
addresses starting with low-order addresses for local- 
ly-created objects, tracking which SID block values 
(Q= A) are in use for such local objects by adding an entry 

50 to mapping table 84 (Fig. 5). for instance. An object point- 
er (P 0 Q()Ro) is tnen created in the base space at step 90. 

A* requirement to move object (IJ) to a first process 
different from the base process initiates a system re- 
sponse at step 91. After copying object (IJ) to the first 

5 5 process in step 91 , the address generator assigns a new 
address (A^) in the first virtual address space at step 
92. This is accomplished with reference to object pointer 
(P 0 Q 0 R 0 ) by forcing B.,=R 0 in the first address space. 
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The address generator chooses A } in step 92 by using 
a rule that allocates A-, values for objects restored from 
other systems, such as selecting from a list of available 
high-order addresses. Thus. A A in the first address space 
is selected from the top of the available address list, al- 
though the value A 0 (step 88) was selected from the bot- 
tom of the available address list in the base space. By 
maintaining mapping table 84 (Fig. 5) to link the object 
identifier prefix (I) to SID block value (A) for all objects 
ever present in virtual address space 14, the local ad- 
dress generator (discussed below in connection with Fig. 
8) can quickly select the appropriate value for A^ respon- 
sive to the object identifier prefix (I) information con- 
tained in field (P) of object pointer (PQR). 

In other words, when an object is being restored, the 
address generator first consults table 84 to find object 
prefix value If \ t is already in table 84 : then the cor- 
responding SID block value (Aj) is immediately selected 
from the table tocomplete the new storage address (AB). 
If object identifier prefix (lj) is not present in mapping ta- 
ble 84 : then SI D block value ( Aj) is selected from the top 
of an available address list and the two value entry (l i: 
A;) is added to table 84. Finally, in Fig. 6. a new object 
pointer (PjQjRj) is created and stored by forcing P-,=P 0 
and Q 1 =A 1 (Ft-, is always equal to R 0 =B). 

When moving an object that is part of a network of 
objects (containing pointers to other objects) from one 
address space to another, the internal object pointers 
must also be updated to reflect assignment to a new vir- 
tual address space. Fig. 7 illustrates an exemplary pro- 
cedure for handling these internal object pointer up- 
dates. Assuming that the internal pointer locations in 
each object being moved are known (the AS/400 system 
accomplishes this by appending pointer tags to pointer 
fields within an object), the internal pointers can easily 
be updated synchronously whenever restoring an object 
to a new address space. This is simply done by looking 
up object identifier prefix (I) for each internal pointer in 
mapping table 84 (Fig. 5) to identify a corresponding SI D 
block value (A) and then updating the internal pointer 
field (Q=A) corresponding thereto. If object identifier pre- 
fix (I) does not appear in mapping table 84, then a new 
SID block value (A) is assigned and the two value entry 
(I, A) is added to table 84. 

However as shown in Fig. 7 ; internal pointers may 
also be updated asynchronously (lazy update) by using 
the fourth object pointer field (S) 76. In Fig. 7, step 86 is 
followed by step 96, wherein a multiplicity of internal ob- 
ject pointers (SPQR) are created for object in the base 
virtual address space. In step 98, the original object is 
linked to this multiplicity of other objects through the stor- 
age of internal object pointers (SPQR). Similarly, after 
step 91 , the flag field (S) is updated for all internal point- 
ers at step 1 00 by changing the flag field value to a pre- 
determined value S w representing restoration of the 
base object (U) to a first process. Following completion 
of steps 92 and 94 : each internal object pointer (S W PQR) 
is then asynchronously updated at step 102 to reflect 
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completion of the transfer to the first virtual address 
space. For instance, internal pointer update step 102 
may be deferred until the first reference to the copied 
object. Step 102 may then be accomplished in the man- 
s ner discussed above in connection with mapping table 
84. 

As an alternative to using type field (S) 76 : the op- 
erating system may reserve a specific value of part (A) 
72 that represents an "unresolved address". This estab- 

10 Nshes a range of virtual addressing that is never allocat- 
ed by the address generator, raising a "segment fault" 
when referenced with that prefix. Such special value re- 
places part (Q) 76 when the object address is unre- 
solved. The effect is to conserve object identifier 54 while 

is invalidating local object address 60. When a user at- 
tempts to use the invalid local object address, the system 
detects a segment fault, which is then used to initiate the 
"lazy update" of unresolved addresses by replacing part 
(Q) 76 with the correct part (A) 72 value from mapping 

20 table 84. This alternative internal pointer flagging 
scheme can be advantageously used in any system em- 
ploying a standard storage protection mechanism. 

Fig. 8 provides an exemplary illustration of the data 
and process objects required in each virtual address 

25 space, exemplified by virtual address space 14. for the 
system of this invention. Mapping table 84 is discussed 
above in connection with Fig. 5. The local address gen- 
erator 104 is also discussed above in connection with 
Figs. 6 and 7. An object identifier generator 106 is cou- 

30 pied to local address generator 104 and is responsible 
for assigning permanent object identifiers to objects cre- 
ated in virtual address space 14. Local address genera- 
tor 104 is coupled to mapping table 84 and also to an 
available address list 108 : using information from both 

^5 to select addresses for new and restored objects in the 
manner discussed above. The object pointer generator 
110 is coupled to local address generator 104 and from 
there to object identifier generator 106, thereby permit- 
ting the creation of object pointers as discussed above 

io in connection with Figs. 4A-4B. Finally, an internal point- 
er updater 1 1 2 functions to update all pointers internal to 
restored objects in the manner discussed above in con- 
nection with Fig. 7. The program object and data object 
elements shown in Fig. 8 are also coupled to operating 

15 system 36 discussed above in connection with Figs. 1 
and 2. 



Claims 

50 

1. In a multitasking network of one or more computer 
systems with distributed memory means for storing 
data and data structures, including a plurality of 
objects each created by some one of a plurality of 
55 concurrent processes each associated with at least 
one of a plurality of virtual address spaces in said 
distributed memory means : said each object being 
stored upon creation in an associated said virtual 
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address space at a base object address (A 0 B 0 ) with 
a first part (A 0 ) and a second part (B 0 ) : said each 
object including an object identifier (IJ) with a first 
part (I) and a second part (J=B 0 ), a method for mov- 
ing said each object to a second said process asso- 
ciated with a second said virtual address space, said 
method comprising the steps of: 



determined'value denoting pending relocation 
of said each object to a new process: and 

(f) for each said internal object pointer (SPQR), 
responsive to said fourth part (S) having said 
first predetermined value, performing the steps 
of 



(a) combining said object identifier (IJ) and said 
base object address (A 0 B 0 ) to produce a base w 
object pointer (P 0 GoRo) with a first P art ( p o =l ): 

a second part (Q 0 =A 0 ) and a third part 
(R 0 ^J=B 0 ); 

(b) associating said base object pointer is 
(P 0 QqR 0 ) with said each object in said distrib- 
uted memory means: 

(c) selecting a first object address (A, B^ ) with a 
first part (A A ) and a second part (B^ ) in said sec- 20 
ond virtual address space such that B^B^J: 

(d) if not already present, copying said each 
object to said second object address (AjBj) in 
said second virtual address space in said dis- zs 
tributed memory means: and 



(f. 1 ) selecting a new object address ( AB) in said 
second virtual address space such that B=R, 
and 

(f.2) replacing said each internal object pointer 
(SPQR) with a new internal object pointer 
(S n P n Q n R n ) such that P n =R Q n =A, R n =R and 
said fourth part S n equals a second predeter- 
mined value denoting completion of said relo- 
cation of said each object. 

The method of claim 3 wherein said selecting step 
(f.1) comprises the steps of: 

(f. 1 . 1 ) if there exists an entry (PjQJ in said object 
mapping table such that Pj=P then selecting 
said new object address (AB) such that A=Qj: 
otherwise 



(e) associating a second object pointer 
(PjQ, R, ) with said copied object in said distrib- 
uted memory means such that P 1 = P 0 -I : Q 1 =A 1 so 
and R 1= R 0 r:j. 

The method of claim 1 wherein said each process 
further includes, in an associated said virtual 
address space, an object mapping table for storing 3S 
an entry (PjQj) representing the first part (P-) and the 
second part (Qj) for each said object pointer created 
by said process and wherein said selecting step (c) 
comprises the steps of: 

40 

(c. 1 ) if there exists an entry (PjQj) in said object 
mapping table such that PpP Q: then selecting 
said second object address (A^) such that 
A^Q;: otherwise 

45 

(c.2) adding a new entry (P^ ) to said mapping 
table such that P 1 =P 0 and Q } = A 1 . 

The method of claim 1 or 2 wherein said distributed 
memory means further includes a plurality of net- so 
worked objects each including one or more internal 
object pointers (SPQR) referring to other said net- 
worked objects, each said internal object pointer 
(SPQR) including a fourth part (S), said method fur- 
ther comprising the steps of: ss 

(d.1) replacing said fourth part (S) of each said 
internal object pointer (SPQR) with a first pre- 



(f. 1 .2) adding a new entry (P n Q n ) to said map- 
ping table such that P n =P and Q n = A. 

5. The method of claim 3 or 4 wherein said performing 
step (f) is executed asynchronously with said replac- 
ing step (e). 

6. In a multitasking network of one or more computer 
systems with distributed memory means for storing 
data and data structures, including a plurality of 
objects each created by some one of a plurality of 
concurrent processes each associated with at least 
one of a plurality of virtual address spaces in said 
distributed memory means, said each object being 
stored in an associated said virtual address space 
at an object address (AB) with a first part (A) and a 
second part (B), said each object including an object 
identifier (IJ) with a first part first (I) and a second 
part (J), a data structure for denoting the global 
object identifier (IJ) and the local virtual object 
address (AB) of said each object, said data structure 
comprising: 

a first part (P) representing said first part (I) of said 
global object identifier: 

a second part (Q) representing said first part (A) of 
said local virtual object address: and 
a third part (R) representing said second part (J) of 
said global object identifier, wherein said first and 
third parts (IJ) are held invariant over said network 
and J=B. 
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The data strucutre according to claim 6 to be used 
in a system for moving said each object to a second 
^iffF8eess asio8ia^^hTll^^ : id virtual " 
address space : said system comprising: 
pointer generator means coupled to said associated s 
virtual address space in said distributed memory 
means for combining said object identifier (IJ) and 
said base object address (A 0 B 0 ) to produce a base 
object pointer (P 0 G(A)) witn a first P art (Po =, )= a sec- 
ond part (Q 0 =A 0 ) and a third part (R 0 =J=B 0 ): 10 
first linking means coupled to said pointer generator 
means in said distributed memory means for asso- 
ciating said base object pointer (P 0 Q 0 R 0 ) with said 
each object: 

address generator means coupled to said second *5 
process in said distributed memory means for 
selecting in said second virtual address space a first 
object address ( A 1 ) with a first part (A^ ) and a sec- 
ond part (B-,) such that B^B^J: 

copying means coupled to said second process in 20 
said distributed memory means for copying said 
each object to produce a copied object at said sec- 
ond object address (A^) in said second virtual 
address space in said distributed memory means: 
and 25 
second linking means coupled to said copying 
means in said distributed memory means for asso- 
ciating a second object pointer (P^^) with said 
copied object in said second virtual address space 
such that P^Pq^L Q-^Aj and R 1= R 0 =J. so 
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relocation of said each object to a new said process: 

ess in said distributed memory means for selecting 
a new object address (AB) in said second virtual 
address space such that B=R for each said internal 
object pointer (SPQR): and 

updating means coupled to said address selecting 
means for replacing said each internal object pointer 
(SPQR) with a new internal object pointer (S n P n . 
Q n R n ) such that P n =R Q n =A, R n =R and said fourth 
part S n equals a second predetermined value denot- 
ing completion of said relocation of said each object 
to said second virtual address space. 



The system of claim 7 further comprising: 
an object mapping table coupled to said each proc- 
ess in said associated virtual address space for stor- 
ing an entry (PjQj) representing the first part (P ; ) and 35 
the second part (Q f ) for each said object pointer cre- 
ated by said each process: 

entry restoring means coupled to said object map- 
ping table in said each associated virtual address 
space for selecting said second object address 40 
( A 1 B 1 ) such that A^ -Qj if there exists an entry (PjQj) 
in said object mapping table such that Pj=P 0 ; and 
entry creating means coupled to each object map- 
ping table in said each associated virtual address 
space for adding a new entry (P^) to said each ^5 
mapping table such that P^Pq and Q^A,. 



The system of claim 7 or 8 wherein said distributed 
memory means further includes a plurality of net- 
worked objects each including one or more internal so 
object pointers (SPQR) referring to other said net- 
work objects, each said internal object pointer 
(SPQR) including a fourth part (S) s said system fur- 
ther comprising: 

flagging means coupled to said each process in said- ss 
distributed memory means for replacing said fourth 
part (S) of each said internal object pointer (SPQR) 
with a first predetermined value denoting pending 



EP 0 700 000 A2 



r 
i 

L 



/ — 1- 

PROC 




^ ,v 
PROC 




PROC 




PROC 



10 



o 

/ET~ETT77 
tiGL£2J2/ 






I BUS J 



z 



J 



CPU 



_^ 32 34^ 



40 



BUS 
INTERFACE 



TAPE 



I/O DEVICE 



38 



1 



REMOTE 
COMPUTER(S) 



12 



22 



CO 
CO 



PRIMARY 
MEMORY 



OPERATING 
SYSTEM 



MEMORY 
MANAGER 



f 



SECONDARY 
MEMORY 



FIG. 1 (PRIOR ART) 



u 



2\. 



USER 
PROCESS 1 



42 



CALL 



■50 



z: 



16 



USER 
PROCESS 2 



18 



USER 
PROCESS N 



36 



26 



24 



USER 
MODE 



^1 



52 



RETURN 



EXECUTIVE 



KERNEL 



HARDWARE 



KERNEL 
MODE 

■ 44 

-46 
■48 



FIG. 2 (PRIOR ART) 



EP 0 700 000 A2 



14 



PROCESS A 
MAPPING TABLE 



PA 


QA 


11 


A1 


12 


A2 


13 

• 


A3 

• 


• 
• 

Ii 


• 

A*i 



84 



16 



PROCESS B 
MAPPING TABLE 



PB 


QB 


n 


A1 


12 


A2 


13 

• 
• 


A3 

• 


• 

Ii 


• 
• 

Ai 



FIG. 5 



I 




J 


ADDRESS 

SPACE 
z ID 


LOCAL OBJECT ID 


SEGMENT 
ID 


OFFSET 



54 



58 FIG. 3A 



56 



62 



SEGMENT ID 



64 



60 



OFFSET 



A 



B 



FIG. 3B 



T 
Y 
P 
E 



OBJECT ID 
PREFIX 
79 



8 



SID 
BLOCK 



82 



OBJECT ID 
SUFFIX 



74 



80 



SEGMENT ID 



OFFSET 



Q 



R 



75 



68 



76 
76 



66 



77 
- 70 



78 



75 



72 



R 



B 



FIG. 4 A 



66 



FIG. 4B 



77 



7U 



EP 0 700 000 A2 



CREATE OBJECT 
IJ 

IN BASE PROCESS 



I 



90 



STORE IJ 


^ — 88 


CREATE AND 


AT Ao Bo 
IN BASE SPACE 




STORE OBJ 




POINTER 
Pn QnRn 



COPY IJ 


^ — 91 


TO FIRST 




PROCESS 




1 




STORE IJ 


^ — 92 


AT M Bi 




IN FIRST SPACE 




WHERE B 1 = R 0 





UPDATE AND 
STORE NEW 
OBJ POINTER 

P 1 Qi Ri 

WHERE = P Q 
AND Q 1 = A 1 



94 



FIG. 6 



• 


EP O 700 000 A2 


CREATE OBJECT 


- — 86 


IJ 




IN BASE PROCESS 





LINK IJ TO A 
MULTIPLICITY OF 
OTHER OBJECTS 
SPQR 



I 



78 



i 



96 



CREATE AND STORE A 
MULTIPLICITY OF 
INTERNAL OBJECT POINTERS 
SPQR IN OBJECT IJ 
IN BASE SPACE 



STORE IJ 
AT AoBo 
IN BASE SPACE 



88 



CREATE AND 
STORE OBJ 

POINTER 
S 0 P 0 Q 0 R 0 



COPY IJ 
TO FIRST 
PROCESS 



91 



UPDATE MULTIPLICITY 
OF INTERNAL OBJECT 
POINTERS S=>S W 



I 



100 



90 



STORE IJ 
AT Ai Bi IN 
FIRST SPACE 
WHERE B 1 = Rq 



92 



UPDATE AND 
STORE NEW 
OBJ POINTER 

Si Pi Q1R1 

WHERE = P 0 

Q1 = A1 
s 1 = s 0 



ASYNCHRONOUSLY UPDATE 
EACH INTERNAL OBJECT 

POINTER S W PQR TO 
ACCOMMODATE TRANSFER 



TO FIRST SPACE S 



W : 



102 



94 



FIG. 7 



EP 0 700 000 A2 





oo 

o 



LU 


CO 


-J 


CO 


CO 


<f 


UJ H- 


AIL, 


cr co 

Q 


> 


< 


< 





cr 

LU 



LU 



5 < 
y ^ O 

O Q_ 

2^3 




co 



LU 
O 
< 
CL. 
CO 

CO 
CO 
LU 
CC 
Q 
Q 
< 



< 
ZD 



(19) 



Europaisd^VIPatentamt 

European Patent Office 
Office europeen des brevets 




I 



(12) 



(88) Date of publication A3: 

02.01.1997 Bulletin 1997/01 



(1D EP 0 700 000 A3 

EUROPEAN PATENT APPLICATION 

(51) intci * G06F 12/02 



(43) Date of publication A2: 

06.03.1996 Bulletin 1996/10 



(21) Application number: 95480098.3 

(22) Date of filing: 24.07.1995 



(84) 


Designated Contracting States: 


• Sirjani, Abolfalz 




DE FR GB 


Austin, Texas 78729 (US) 






• Voldal, Erik Edward 


(30) 


Priority: 30.08.1994 US 299042 


Rochester, Minnesota 55901 (US) 


(71) 


Applicant: International Business Machines 


(74) Representative: Lattard, Nicole 




Corporation 


Compagnie IBM France 




Armonk, N.Y. 10504 (US) 


Departement de Propriete Intellectuelle 






06610 La Gaude (FR) 


(72) 


Inventors: 


• 


Munroe, Steven Jay 






Rochester, Minnesota 55901 (US) 





(54) System and method combining a global object identifier with a local object address in a 
single object pointer 



CO 
< 
O 

o 
o 

o 
o 

o 

CL 



(57) An object pointer data structure for efficiently 
combining an object identifier and an object address for 
use in object-oriented programming systems. An object 
address is a value that allows a client application or 
process to conduct high-performance operations on an 
object in the client's local virtual address space. An ob- 
ject identifier is a value that can be used to uniquely 
identify an object for the lifetime of that object across 
some defined domain, such as an entire universe of 
computer systems. The data structure of this invention 
defines an object pointer that is larger than the object 
address but smaller than the combination of the object 
identifier and object address. The truncated object 
pointer structure preserves all information from both ob- 
ject address and object identifier by forcing a portion of 
the local object address in each address space to be 
equal to a portion of the invariant object identifier A local 
pointer mapping table may be used for efficiency in as- 
signing local addresses to restored objects in each proc- 
ess. 



_ CX £ 

5 K < 

yj 5 2 

co 5 ^ 

° 2 g 

o 



V 



2- co 



V 



< Ul t- 

393 



<Su; 



</> o 

-J XA J— 
< Ld < 

O O LU 
-l O 2 
< LU 
O 



^ ^ 2 

m 3 llj 

O IU 2 
Q LU 
— O 



EP 0 700 000 A3 



Europe™ Patem EUROPEAN SEARCH REPORT AppUc2tIon NurabCT 

0fncc EP 95 48 0098 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THK 
APPLICATION flnt.CI.li) 



US-A-4 660 142 (CLANCY GERALD F ET AL) 21 
April 1987 

* abstract * 

EP-A-0 542 483 (IBM) 19 May 1993 

* abstract * 



1,6 



1,6 



GO6F12/02 



TECHNICAL FIELDS 
SEARCHED (Int. CI. 6) 



G06F 



The present search report has been drawn up for all claims 



Pile* of lexxfc 


Dale *f completion of the tejrck 


Ex miner 


THE HAGUE 


25 October 1996 


Ledrut, P 



CATEGORY OK CITED DOCUMENTS 

X : particularly relevant if taken alune 

Y : particularly relevant it combine! with another 

document or the same category 
A : technological background 
O : norv- writ ten disclosure 
P : intermediate document 



ineory or principle underlying the invention 
earlier patent document, but published on, or 
after the tiling date 
document cited in the application 
document cited tor other reasons 



& : member of the same patent family, corresponding 
document 



